1. Field of the Invention
This invention relates to the field of integration of enterprise applications and systems, and more particularly to the integration of heterogeneous systems in which support for qualities of service, such as synchronization and recovery, may be required by some subsystems, and provided or not provided by other subsystems.
2. Background of the Invention
Enterprise Application Integration (EAI) is key to many companies” business strategies. The ability to integrate existing systems with new systems is seen as an essential in, for example, web-enabling existing applications. A fundamental part of EAI is the ability to coordinate updates made to disparate systems that form part of an enterprise information system. For example, a new application, running on an application server, which brings together in an enterprise information system two existing database applications and an Enterprise Resource Planning, or ERP, system (for example, SAP R/3) needs to be able to coordinate updates made to those three systems. The inability to do so could result in loss of data integrity.
The technology, which provides the access to the systems and the integration with the application server, is often referred to as Connectors. Connector coordination can be provided through two interfaces, the coordinator and the resource. Resources can represent Enterprise Information Systems, as shown in FIG. 2. An Enterprise Information System may comprise databases, ERP systems, and the like. The Resources require certain Quality of Service commitments from their environments (via the Coordinator). (“Quality of Service” is used here to refer to such characteristics of systems as their level of support for recoverability of data after a system failure. Some systems provide full recovery support, while others do not. Other such characteristics are, for example, the ability or otherwise to support asynchronous processing.) The use of coordinator and resource interfaces is found in transaction services such as that provided by the Object Management Group's (OMG) CORBA specification, known as the Object Transaction Service (OTS). In general with such services, the implementation of both the resource and the coordinator is provided by the same organization. This means that the Quality of Service (QOS) required and provided by each is known from the beginning.
EAI introduces a new dimension of difficulty which is unavoidable due to the large numbers of heterogeneous systems which need to be integrated, and the large number of application servers which need to provide integration. A significant problem is that the implementers of the coordinator or coordinators and the implementers of the resource or resources may be different organizations whose members may never have met or communicated. In an attempt to overcome the differences between systems supplied by different vendors, the J2EE Connector Architecture specification allows a resource adapter to describe a resource's capabilities in a deployment descriptor, but the application server and the coordinator are required to support all possible options, which is cumbersome for some lightweight runtimes.
Measures of QOS for coordinators and resources include commit phase support (also known as sync level support), which may be one phase commit or two phase commit, and recovery support (that is, whether or not logging is supported to preserve integrity beyond a system crash).
The ways in which these QOS are provided, and the QOS resulting from different coordinator and resource pairings can vary greatly, and some pairings may be invalid. The provision of commit phase support and recovery support is essential in systems which have a characteristic known as “transactionality”.
The term “transactionality” is used in the field of data processing to refer to the characteristic of a piece of data processing work that may be defined as having a necessary unity. For example, the data processing task of processing a cash withdrawal from an automated teller machine has several elements, but all must take place for the transaction to be completed. The user's identity must be verified, the cash must be issued, and the user's account must be updated to reflect the new balance after the withdrawal, and so on. If the machine runs out of cash or suffers some other failure, so that the withdrawal does not take place, the user's account must not be updated, or, if it has already been updated before the point of failure, the update must be cancelled so that the account returns to its previous state. For background information on the properties of transactions, see Transaction Processing: Concepts and Techniques, J. Gray and A. Reuter.
Clearly, however, there exist more complex business environments requiring characteristics other than those of this simple, unitary transaction model, and these are the subject of continuing study and research. For background information on more complex transaction environments, see Database Transaction Models, Ahmed K. Elmagarmid, ed., and Advanced Transaction Models and Architectures, Jajodia and Kerschberg, eds. Examples taken from real life include, for example, the booking of a vacation, which may involve multiple transactions to book flights and hire cars, reserve hotel rooms, and so on, using a number of different systems independently developed by different suppliers. The management of transactions and coordination of updates in such environments adds to the complexity of the problems faced by application developers, and the cumbersome nature of existing solutions is unacceptable in environments in which performance is critical.